For speed of communications and cost effectiveness, individuals, businesses, and other organizations frequently exchange electronic data through e-mail, the Internet, and other networks and systems. Companies increasingly rely on third-party applications on the Internet to accomplish a wide range of intended purposes, often involving the exchange of electronic documents.
Electronic Data Interchange (EDI)
To help establish compatibility for electronic data exchanges, the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) has developed a set of standards for electronic data interchange (EDI) called the X12 standards, which defines the content and structure for data contained in electronic data files. For example, in EDI X12, a standard HIPAA (Health Insurance Portability and Accountability Act) “837P” interchange document represents an electronic data file used for filing patient claims to a health insurer.
Example of an EDI Document
An EDI document is a flat list of text, the divisions of which are not easy to determine. The following, abbreviated code shows a typical EDI interchange document:
ISA*00* *00*   *ZZ*WEBIFYSE  *ZZ*00AAA*020220*1243*U*00401*100000034*0*T*:~GS*HS*WEBIFYSE*00AAA*20020220*2314*123456789*X*004010X092Al~ST*270*3120~BHT*0022*13*10001234*19990501*103045*RT~HL*1**20*1~NM1*PR*2*SampleBCBS*****FI*999999999~HL*2*1*21*1~NMI*1P*2*SampleClinic*****FI*888888888~REF*1J*0035~HL*3*2*22*0~TRN*1*93175-012547*9323233345~NMl*IL*1*SMITH*JOHN*M***MI*333440623~DMG*D8*19510918~DTP*472*RD8*20031201-20031201~EQ*30**FAM*GP~SE*14*3120~GE*1*123456789~IEA*1*100000034~
In this interchange document, the elements ST and SE represent the start and end of a business transaction that may contain many additional elements.
An EDI document may be associated with more than one entities.
Example of EDI Transaction Segment
The following line shows a typical segment of an EDI business transaction in an 837P interchange document:
NM1*H*DOE*JOHN*78747
In this example, the letters “DOE” might represent the last name of a specific individual. The field where “DOE” appears might indicate the last name of a patient submitting a claim. Similarly, the numbers “78747” might represent a specific individual's zip code and the field where “78747” appears might indicate the zip code of a patient filing a claim.
Implementation Guides
To promote standardization in the formats used in EDI documents, the Workgroup for Electronic Data Interchange (WEDI) organization has created implementation guides of standard rules. For example, the implementation guide for an EDI document might stipulate that for NM 1, a valid zip code of five characters needs to exist. An implementation guide requirement for a different part of the same EDI document might be that a payer identification number needs to be 45 characters long.
Companion Guides
Implementation guides, however, do not cover the different, often changing requirements of regulatory bodies and individual companies. For example, the states of Florida and Texas would require different ranges of zip code numbers in patient claims. The American Medical Association may have guidelines for patient claims that change over time. And requests to different companies would, of course, require different company names or payer identification numbers. If a company changes its name, a different name or identification number might have to be supplied in patient claims.
To be able to use the EDI documents they receive, companies therefore typically create rulebooks, for example companion guides, to be used on top of implementation guides, to stipulate their particular requirements and the requirements of the bodies that govern them. In FIG. 1, for example, the company at payer server 1 170 may have companion guide 1 410. The company at payer server 2180 may have a different companion guide 420.
Companion guides, which are usually PDF files, are not machine readable, and each, may contain thousands of rules, making them difficult to read and comply with. For example, with over 600 insurance companies in the United States alone, companies that have to send EDI documents to numerous insurance companies have great difficulty identifying and meeting all the requirements in different companion guides. Moreover, other types of EDI documents in other areas of business have similar implementation guides and companion guides for different companies services, so that that challenge of interoperability through different industries is quite large.
Clearing Houses
Business entities, such as health insurance payers, often use third party clearing houses to validate that the EDI documents being sent to the entities from companies such as health care providers comply with the entities' rulebooks or companion guides.
Typically these clearing houses manually write programs or use manually programmed third party engines to identify the requirements in each companion guide and then to automatically analyze each EDI document to discover whether the EDI document meets the requirements of the appropriate companion guide. Such a process is unnecessarily laborious, expensive, and time consuming, because the rules shared among many companion guides have to be written many times.
Therefore there is a need for a method and system that provides a more automatic method to validate the compliance of EDI documents with companion guides.